DATE REVISED: 22 AUGUST 1996
SECTION 6 INFORMATION SYSTEMS SECURITY STANDARDS
This section provides the information system security standards necessary to implement security at the required level of protection.
The standards mandated in this section apply to all Command, Control, Communications, Computers, and Intelligence (C4I) systems. This section provides the security standards applicable to information processing, transfer, modeling and standards, and Human-Computer Interfaces (HCI). This section also addresses standards for security audit and key management mechanisms. Subsection 6.2 addresses mandated security standards, and subsection 6.3 addresses emerging security standards.
The Technical Architecture Framework for Information Management (TAFIM) provides a blueprint for the Defense Information Infrastructure (DII), capturing the evolving vision of a common, multipurpose, standards-based technical infrastructure. The DoD Goal Security Architecture (DGSA), Volume 6 of the TAFIM, provides a comprehensive view of the architecture from the security perspective. The DGSA is a generic architectural framework for developing mission specific security architectures which includes security services for information systems (authentication, access control, data integrity, data confidentiality, non-repudiation, and availability). Although advancements in security theory and technology are needed to develop DGSA-consistent systems, the DGSA concepts and principles can be incorporated into current systems.
Interoperability requires seamless information flow at all levels of information classification without compromising security. The goal is to protect information at multiple levels of security, recognizing that today's DoD systems are "islands" of system-high solutions.
Systems that process sensitive data must be certified and accredited before use. Certification is the technical evaluation of security features and other safeguards, made in support of the accreditation. Accreditation is the authorization by the Designated Approving Authority (DAA) that an information system may be placed into operation. By authorizing a system to be placed in operation, the DAA is declaring that the system is operating under an "acceptable level of risk." Therefore, system developers should open dialog with the Certifier and DAA concurrently with their use of the Joint Technical Architecture (JTA), as DAA decisions can affect the applicability of standards within specific environments.
DoD systems should have adequate safeguards to enforce DoD security policies and system security procedures. System safeguards should provide adequate protection from user attempts to circumvent system access control, accountability, or procedures for the purpose of performing unauthorized system operations.
Security requirements and engineering should be determined in the initial phases of design. The determination of security services to be used and the strength of the mechanisms providing the services are primary aspects of developing the specific security architectures to support specific domains. Section 6 of the JTA is used after operational architectural decisions are made regarding the security services needed and the required strengths of protection of the mechanisms providing those services.
The proper selection of standards can also provide a basis for improved information protection. Although few specific standards for the general topic of "information protection" exist, within Defensive Information Warfare, selecting standards with security-relevant content contributes to the overall improvement of the security posture of information systems.
This subsection identifies the mandatory standards, profiles, and practices for information systems security standards. Each mandated standard or practice is clearly identified on a separate line, and includes a formal reference that can be included within Requests for Proposals (RFP) or Statements of Work (SOW). Appendix B contains a table that summarizes the mandated standards from this section, as well as providing information on how to obtain the standards. The WWW version of Appendix B contains a link to the standard or to the organization that maintains the standard when one is available.
This section contains the mandatory information systems security standards and protocols that shall be implemented in systems that have a need for the corresponding interoperability-related services. If a service is to be implemented in a C4I system, then it shall be implemented at the required level of protection using the associated security standards in this section. If a service is provided by more than one standard, the appropriate standard should be selected based on system requirements.
Technical evaluation criteria to support information system security policy, and evaluation and approval, disapproval, and accreditation responsibilities are promulgated by DoD Directive (DoDD) 5200.28. Based on the required level of trust, the following information processing security standards are mandated.
The following standards are mandated for the development and acquisition of application software consistent with the required level of trust:
If FORTEZZA services are used, the following are mandated:
For the application platform entity, security standards are mandated for data management services and operating system services.Security is an important part of other platform service areas, but there are no standards mandated.
The following standard is mandated for data management services consistent with the required level of trust:
For the application platform entity, the following standard is mandated for the acquisition of operating systems consistent with the required level of trust:
Security auditing is a review or examination of records and activities to test controls, ensure compliance with policies and procedures, detect breaches in security, and indicate changes in operation. Security alarm reporting is the capability to receive notifications of security-related events, alerts of any misoperations and security services and mechanisms, alerts of attacks on system security, and information as to the perceived severity of any misoperation, attack, or breach of security.
The following standard is mandated for security auditing or alarm reporting:
Authentication supports tracing security-relevant events to individual users. The following standard is mandated:
If Open Software Foundation (OSF) Distributed Computing Environment (DCE) Version 1.1 is used, the following authentication standard is mandated:
This section discusses the security standards that shall be used when implementing information transfer security services. Security standards are mandated for the following information transfer areas: end system (host standards), and network (internetworking standards).
Security standards for host end systems are included in the following subsections.
Host end system security standards include security algorithms, security protocols, and evaluation criteria. The first generation FORTEZZA Cryptographic Card and its successor the Type I Card (formerly known as FORTEZZA Plus) are designed for protection of information in messaging and other applications.
For systems required to interface with Defense Message System, the following standards are mandated:
To achieve interoperability, products must support a common transport protocol. Transport protocols must agree on a common cryptographic message syntax, cryptographic algorithms, and modes of operations (e.g., cipher block chaining). Transport protocols support negotiation mechanisms for selecting common syntax, algorithms, and modes of operation.
The following paragraphs identify security standards that shall be used for the identified types of cryptographic algorithms: message digest or hash, digital signature, encryption, and key exchange.
Message digest or hash algorithms are one-way functions which create a "fingerprint" of a message. They provide data integrity when used in conjunction with other cryptographic functions. If message digest or hash algorithms are required, the following standard is mandated:
Digital signatures provide strong identification and authentication. Related standards include public key certificate standards (X.509) and directory service standards (X.500). If digital signature is required, the following standard is mandated:
Encryption prevents unauthorized disclosure of information during transmission. Systems processing classified information must use a Type 1 NSA-approved encryption product, which can also be used to encrypt sensitive but unclassified information. To provide for lawful authorized access to the keys required to decipher enciphered information for systems requiring strong encryption protection of sensitive but unclassified information, the following standard is mandated:
Key exchange algorithms allow two parties to exchange encryption keys without relying on out-of-band communications. In FORTEZZA applications, the following NSA-developed Type II key exchange algorithm is mandated:
The following standard is mandated for DoD systems that are required to exchange security attributes, for example sensitivity labels:
Establishment of a certificate and key management infrastructure for digital signature is required for the successful implementation of the security architecture. This infrastructure is responsible for the proper creation, distribution, and revocation of end users' public key certificates. The following standard is mandated:
MIL-STD-2045-18500 is based on Version 3.0 of the Message Security Protocol (MSP) documented in SDN 701, Secure Data Network System Message Security Protocol, Revision 1.5, 1 August, 1989. The following messaging protocol is mandated for DoD message systems that are required to exchange sensitive but unclassified and classified information:
The following key management protocol is mandated:
The following standards are mandated consistent with the required level of trust:
Mandated network security standards are included in subsection 6.2.3.2.1.
See subsection 6.2.3.1.1.1. When key escrow encryption is required, the following standard is mandated:
When network layer security is required, the following security protocol is mandated:
The following standard is mandated for DoD systems that are required to exchange security attributes, for example sensitivity labels:
There are currently no security standards mandated for transmission media.
At this time, no information modeling and information security standards are mandated. It should be noted that process models and data models produced should be afforded the appropriate level of protection.
DoD 5200.28-STD, DoD Trusted Computer System Evaluation Criteria (TCSEC), December 1985, specifies the minimal security requirements associated with a required level of protection for DoD automated systems. HCI security-related requirements may include authentication, screen classification display, and management of access control workstation resources.
For systems employing graphical user interfaces, the following guideline is mandated:
The standards listed in this subsection are expected to be elevated to mandatory status when implementations of the standards mature.
The emerging security standards described in this section are drawn from work being pursued by ISO, IEEE, IETF, Federal standards bodies, and consortia such as the Object Management Group (OMG). Section 6.3 is structured to mirror the overall organization of the JTA so that readers can easily link security topics with the related subject area in the sections of the JTA (information, processing, information transfer, information modeling and information exchange, and human-computer interface) and their subsections.
Information processing security standards are emerging in the following areas: application software entity and application platform entity (software engineering, operating systems, and distributed computing services).
Emerging application software entity standards include evaluation criteria and WWW security-related standards.
The Common Criteria for Information Technology Security Evaluation (CC) is an effort by the governments of North American and European nations to develop a common criteria for developing trusted information technology products that can be used to help protect important information of government and private sectors. It uses input from the European Information Technology Security Evaluation Criteria (ITSEC), the Canadian Trusted Computer Product Evaluation Criteria (CTCPEC), the U.S. draft Federal Criteria for Information Technology Security, and the TCSEC (DoD 5200.28-STD). CC Version 1.0 is undergoing international review and testing for use in evaluations of products prior to being fully accepted within Europe and North America. The CC is expected to replace DoD 5200.28-STD. Common Criteria (Parts 1-3) has been formally adopted by ISO as the basis for its future work in security criteria. The reference to the ISO adopted CC is "ISO/IEC JTC1/SC27/WG3 N304, 23 April 1996".
"The Secure Sockets Layer (SSL) Protocol Version 3.0", A. Freier, P. Karlton, P. Kocher, 13 March 1996, draft-freier-ssl-version3-01.txt, an Internet Draft supporting WWW security, is being considered for standardization. The SSL protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. SSL runs above the transport layer.
For the application platform entity, security standards are emerging for software engineering, operating systems, and distributed computing services.
For software engineering services, security standards are emerging for Generic Security Service (GSS)-Application Program Interface (API) and POSIX areas.
The GSS-API, as defined in RFC-1508, September 1993 (IETF), provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. RFC-1508 defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment. The Internet Draft "GSS-API, Version 2," J. Linn, 20 February 1996, draft-ietf-cat-gssv2-05.txt revises RFC-1508, making specific, incremental changes in response to implementation experience and liaison requests.
The Internet Draft, "Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)," C. Adams, 18 February 1996, draft-ietf-cat-idup-gss-04.txt, extends the GSS-API (RFC-1508) for non-session protocols and applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated "receivers" of the data unit. An example application is secure electronic mail where data needs to be protected without any on-line connection with the intended recipient(s) of that data. Subsequent to being protected, the data unit can be transferred to the recipient(s) - or to an archive - perhaps to be processed as unprotected only days or years later.
The following draft IEEE standards define a standard interface and environment for POSIX-based computer operating systems that require a secure environment: IEEE P1003.1e, POSIX Part 1: System API - Protection, Audit, and Control Interfaces [C Language], Draft 15 (reballot March 1996) and IEEE P1003.2c, POSIX Part 2: Shell and Utilities - Protection and Control Interfaces, Draft 15 (reballot March 1996). These draft standards define security interfaces to open systems for access control lists, audit, privilege, mandatory access control, and information label mechanisms and are stated in terms of their C bindings.
Operating system services security standards are emerging in the following areas: evaluation criteria and authentication.
See section 6.3.2.1.1 for description of the following emerging standard that is expected to replace DoD 5200.28-STD: Common Criteria for Information Technology Security Evaluation.
RFC-1938, A One-Time Password System, provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. The One-Time Password System evolved from the S/KEY One-Time Password System that was released by Bellcore.
DCE Authentication and Security Specification (P315) is a draft Open-Group Specification for DCE.
The Common Object Request Broker Architecture (CORBA), OMG 95-12-1, December 1995, is emerging. CORBA Security Services define a software infrastructure that supports access control, authorization, authentication, auditing, delegation, non-repudiation, and security administration for distributed object-based systems. This infrastructure can be based on existing security environments and can be used with existing permission mechanisms and login facilities. The key security functionality is confined to a trusted core that enforces the essential security policy elements. Since the CORBA Security Services are intended to be flexible, two levels of conformance may be provided. Level 1 provides support for a default system security policy covering access control and auditing. Level 1 is intended to support applications that do not have default policy. Level 2 provides the capability for applications to control the security provided at object invocation and also for applications to control the administration of an application-specific security policy. Level 2 is intended to support multiple security policies and to provide the capability to select separate access control and audit policies.
Security standards are emerging for the following information transfer areas: end systems (host standards) and network (internetworking standards).
Emerging end system security standards include host standards discussed in the following subsection.
Security standards are emerging for host end systems in the security protocols and public key infrastructure areas discussed in the following subsections.
The Common Internet Protocol (IP) Security Options (CIPSO) of the following emerging standard is expected to adopt MIL-STD-2045-48501, Common Security Label: Trusted Systems Interoperability Group (TSIG) Trusted Information Exchange for Restricted Environments (TSIX (RE)) 1.1.
The following Integrated Services Digital Network (ISDN) security protocol is emerging: ISP-421, Revision 1.0: The ISDN Security Program (ISP) Security Association Management Protocol (SAMP), 15 May 1994.
The following are emerging standards for Local Area Network (LAN) security: IEEE 802.10c/D13, Standard for Interoperable LAN Security-Part C: Key Management, and IEEE 802.10g/D7, Standard for Interoperable LAN Security - Part G: Standard for Security Labeling within Secure Data Exchange.
MIL-STD-2045-18500 is based on Version 3.0 of the MSP documented in SDN 701. MSP is under revision to Version 4.0 to accommodate, in part, Allied requirements. When the revision to MSP is completed DoD is expected to move to MSP Version 4.0.
The emerging FIPS PUB JJJ is based on ISO/IEC 9798-3: 1993, Entity Authentication Using a Public Key System and will provide a standard for Public Key Cryptographic Entity Authentication Mechanisms for use in public key based challenge-response and authentication systems at the application layer within computer and digital telecommunications systems.
Emerging network standards are listed in subsection 6.3.3.2.1.
RFC-1825, "Security Architecture for the Internet Protocol," R. Atkinson, August 1995, describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. Each security mechanism is specified in a separate document. RFC-1825 also describes key management requirements for systems implementing those security mechanisms. It is not an overall Security Architecture for the Internet, but focuses on IP-layer security.
RFC-1826, "IP Authentication Header (AH)," R. Atkinson, August 1995, describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. An AH is normally inserted after an IP header and before the other information being authenticated. The AH is a mechanism for providing strong integrity and authentication for IP datagrams. It might also provide non-repudiation, depending on which cryptographic algorithm is used and how keying is performed.
RFC-1827, "IP Encapsulating Security Payload (ESP)," R. Atkinson, August 1995, discusses a mechanism for providing integrity and confidentiality to IP datagrams. In some circumstances, depending on the encryption algorithm and mode used, it can also provide authentication to IP datagrams. Otherwise, the IP AH may be used in conjunction with ESP to provide authentication. The mechanism works with both IPv4 and IPv6.
The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. DNS Security Extensions, D. Eastlake, C. Kaufman, 30 January 1996, draft ietf dnssec-secext-09.txt, describes extensions to the DNS that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security.
Three IEEE LAN standards are emerging: IEEE 802.10, IEEE Standards for Local and Metropolitan Area Networks (MANs): Interoperable LAN/MAN Security (SILS), 1992, discusses services, protocols, data formats, interfaces to allow IEEE 802 products to interoperate. It discusses authentication, access control, data integrity, and confidentiality. IEEE 802.10a, Standard for Interoperable LAN Security-The Model, Draft Jan 1989 shows the relationship of SILS to OSI and describes required interfaces. IEEE 802.10b, Standard for Interoperable LAN Security-Part B: Secure Data Exchange, 1992 deals with secure data exchange at the data link layer.
There are no emerging standards in this area at this time.
Refer to section 6.3.2.1.1 for information pertaining to the following emerging standard that is expected to replace DoD 5200.28-STD:. Common Criteria for Information Technology Security Evaluation.
Refer to section 6.3.3.1.1.2 for information pertaining to FIPS PUB JJJ, Standard for Public Key Cryptographic Entity Authentication Mechanisms.